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Global  Area  Coverage  (G PC)  data  is  stored  data  of  the 
AVHRR  instrument.  The  original  HRPT  resolution  of  1.1  km 
is  reduced  to  about  3.3  by  4.0  km.  There  are  120  scans  per 
minute  with  409  pixels  each.  The  raw  data  are  available 
from  the  National  Climatic  Data  Center  as  tape  copies  that 
generally  contain  calibration  information.  In  order  to 
process  the  data  on  the  SPADS,  the  data  must  be  unpacked 
and  written  to  a  disk  file  in  a  specified  format.  Then, 
the  image  cam  be  transformed  in  either  Mercator  or  Polar 
Stereographic  Projection,  and  the  geographical  background 
may  be  added.  , 


1 .  Introduction 

This  documentation  is  meant  as  an  aid  for  using  the  described  software 
available  for  the  SPADS  Eclipse  S250,  for  maintenance  of  the  software  and  for 
understanding  data  formats  as  well  as  the  techniques  involved  in  processing  the 
GAC  imagery. 

The  NQAA  Polar  Orbiter  Data  User's  Guide  (1)  as  well  as  the  MOAA  Technical 
Memorandum  NESS  107  (2)  are  most  useful  to  understand  the  data  formats  and  the 
retrieval  techniques. 

If  any  errors  are  found  with  these  documents,  the  user  should  not  hesitate 
to  contact  the  responsible  people;  any  constructive  response  will  be 
appreciated . 


2.  The  Raw  Data 
2.1  How  to  Order  Data 

Everybody  working  for  the  SPAD  should  contact  the  department  head  to  get 
the  account  number  to  which  the  fees  for  the  data  copies  should  be  billed  prior 
to  ordering  data. 

Then  a  letter  should  be  written  to  the  National  Climatic  Data  Center, 
following  the  instructions  described  on  page  1-1  of  the  NOAA  Polar  Orbiter  Data 
User's  Guide.  Writing  a  letter  will  pay  off,  since  a  phone  call  is  a  potential 
source  of  misunderstandings.  About  $100  for  a  possibly  faulty  copy  can  be 
saved  this  way. 


Up  to  now,  it  has  been  advisable  to  order  800  BPI  copies  directly 
compatible  with  the  tape  unit  available  to  the  S250.  Since  there  will  be  a 
1600  BPI  tape  unit  available  in  connection  with  the  MV4000,  it  is  recommended 
to  order  1600  BPI  copies  in  the  future.  In  doing  so,  more  data  can  be  written 
to  one  tape.  Since  the  fees  are  charged  per  tape,  money  can  be  saved  again. 

2 . 2  Data  Formats 


2.2.1  The  Tape  Label  (TBM  Header) 

The  first  record  on  the  tape,  described  under  3.0.1  data  set  names  and 
under  3.1.1  TBM  header  in  the  User's  Guide  (1),  is  61  (16-Bit)  words  long  and 
contains  essential  information  about  the  copy  in  ASCII  code.  All  other  records 
on  the  tape  should  be  3220  words  long. 

2.2.2  Data  Set  Header 

The  second  record  is  the  data  set  header.  Only  the  first  35  Bytes  are  of 
any  meaning  to  the  user.  The  rest  are  blanks  to  make  the  header  record  3220 
words  long. 

The  tape  direction  coding  in  the  DACS  status  word  has  probably  been 
faultily  described  in  the  User's  Guide  (1). 

The  content  of  the  first  35  Bytes  has  been  described  on  pages  3-3  through 
3-5  in  the  User's  Guide  (1). 

2.2.3  Data  Records 

Records  3  through  N  (depending  on  the  data  volume)  are  data  records.  Each 
of  these  physical  records  contain  two  logical  records,  one  per  scan.  One 
logical  record  is  1610  words  or  3220  Bytes  long. 

The  first  448  Bytes  (224  words)  of  a  logical  record  contain  information 
about  that  particular  scan,  such  as  scan  line  number,  start  time  of  scan, 
calibration  coefficients  etc.  Bytes  449  through  3176  (2728  Bytes  or  1364 
words)  contain  the  GAC  video  data,  the  rest  is  left  spare. 

GAC  raw  data  have  10  Bit  per  pixel,  with  the  most  significant  Bit  (MSB)  at 
the  left  and  the  least  significant  Bit  (LSB)  at  the  right.  Three  pixels  are 
stored  in  4  Bytes  (2  words),  right  justified.  Thus,  if  all  the  Bits  of  three 
subsequent  pixels  were  set  to  1,  the  4  Bytes  would  look  as  follows: 

word  N  I  word  N+l  I 

001111111111111  111  11111111111111  1| 


I pixel  M 


I ///I pixel  Mtl 


l///lpixel  Mt-2 


I ///I 


Since  the  hardware  available  is  able  to  display  8-Bit  data  only,  the  left 
8  Bits  of  each  pixel  must  be  extracted.  This  can  be  done  using  a  masking  as 
follows: 


pixel  M:  ISHFT  (word  N.and. 37700K, -6 

pixel  Mfrl:  ISHFT  (word  N.and.l7K,4).or.ISHFT(word  N+l.and.l74000K,-12) 
pixel  Mt2:  ISHFT  (word  N+l.and.l774K,-2) 

In  the  last  two  words,  only  the  first  two  pixels  are  of  any  meaning,  the 
third  one  is  zero-filled. 
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Thus  in  the  first  1362  words  of  each  logical  record,  2043  pixels  are 
stored.  Plus  another  2  pixels  in  the  last  two  words  makes  ip  to  2045  pixels 
per  logical  record  or  scan.  Since  there  sure  5  possible  channels  onboard  the 
satellite,  this  results  to  409  pixels  per  channel  per  scan.  In  case  the 
satellite  has  only  4  channels,  the  data  of  the  fourth  channel  are  copied  into 
the  space  reserved  for  the  missing  fifth  channel.  The  data  are  written  in  the 
following  sequence: 

pixel  1  of  channel  1,  pixel  1  of  channel  2,  pixel  1  of  channel  3,  pixel  1  of 
channel  4,  pixel  1  of  channel  5,  pixel  2  of  channel  1,  and  so  on.  Caution: 

The  pixel  values  of  pixels  1,  2  and  409  of  each  scan  have  been  found  to  be  more 
or  less  regularly  set  to  zero. 

2.3  Processing  the  Tape 

2.3.1  Quality  Checks 

The  raw  data  are  not  always  perfect.  To  test  the  tape  for  readability, 
program  TAPE7TST  may  be  run  on  the  NOVA  computer  prior  to  running  POLRGAC,  the 
tape  reading  and  processing  program.  This  is  advisable,  since  POLRGAC  is  able 
to  continue  reading  upon  you  request,  even  if  the  data  is  faulty. 

There  is  also  a  program  available  to  test  the  raw  data  for  proper  time 
sequence  of  all  the  scans  contained  on  the  tape;  this  program  is  called  GTMTST 
(GA C  time  test)  and  nans  on  the  Eclipse  S250.  After  the  run  of  CTTMTST  is 
complete,  the  results  can  be  listed  on  the  line  printer  by  typing:  PRINT 
GIMTST.PR. 

It  is  understood,  that  these  testing  procedures  use  a  lot  of  paper. 
Ultimately,  it  seems  to  be  worth  it,  since  working  with  faulty  data  can  never 
be  satisfactory.  Anyhow,  GTMTST  should  only  be  run,  if  POLRGAC  generates  a 
strange  locking  image  on  the  display.  This  visual  quality  control  provided  by 
POLRGAC  is  still  not  perfect,  since  missing  scans  in  the  original  satellite 
data  may  have  been  omitted  in  the  copy.  So,  the  efficiency  of  testing  the  data 
depends  largely  upon  the  user's  personal  judgment. 

2.3.2  Running  POLRGAC 

It  seems  not  to  be  necessary  to  give  too  many  details,  because  the  program 
documentation  of  POLRGAC  is  already  pretty  detailed.  Information  that  goes 
beyond  the  knowledge  necessary  to  run  POLRGAC  is  probably  more  useful  to  the 
user. 

Prior  to  running  the  program,  one  should  know  which  channels  one  wants  to 
work  with,  and  whether  or  not  one  needs  a  temperature/albedo  look-up  table.  It 
is  always  advisable  to  write  the  header  information  of  each  image  being 
processed  to  the  printfile  POLRGAC. PR;  this  enables  the  user  to  keep  track  of 
the  imagery  that  has  been  processed.  The  same  is  valid  for  the  look-up  tables, 
that  may  be  written  to  printfile  GMXAL.PR.  The  information  contained  in 
POLRGAC.PR  is  essential  for  the  generation  of  the  proper  ephemeris  lateron. 
Thus,  holes  in  the  raw  data,  even  missing  lines,  are  not  necessarily  a  reason 
to  keep  POLRGAC  from  performing  its  job. 

2.3.3  The  Albedo  and  Temperature  Look-up  Tables 

The  techniques  involved  in  generating  these  tables  (subroutine  GACCAL)  are 
in  accord  with  the  latest  information  available.  Details  can  be  found  in  the 
User's  Guide  (1)  as  well  as  in  the  NCAA  Technical  Memorandum  NESS  107  (2). 


2.3.4  Data  Time  Sequence 

Since,  on  the  one  hand,  there  is  a  chance  that  the  time  sequence  of  the 
data  c*i  tape  may  be  reversed,  and,  on  the  other  hand,  GACMOPS,  the 
transformation  program,  expects  the  data  as  being  time  incrementing,  POLRGAC 
would  flip  the  whole  image  upside  down  prior  to  storing  it  to  disk,  if  it 
encountered  time  decrementing  data. 

The  ephemeris  file  used  in  connection  with  GACMOPS  lateron  is  always  time 
incrementing. 

2.3.5  Satellite  ID 

POLRGAC  is  able  to  look  for  the  satellite  ID  and  to  display  it  on  the 
dialogue  screen  in  the  after  launch  code  for  TIROS-N  through  NQAA-8.  For  all 
future  satellites  of  the  same  series,  it  would  give  the  pre  launch  code,  e.g. 
NOAA-E  for  NQAA-8.  Thus,  if  the  user  wishes  to  get  the  after  launch  name  for 
future  satellites,  the  corresponding  source  code  has  to  be  changed  in  POLRGAC. 

2.3.6  The  Processed  Image 

The  image  displayed  on  the  screen  is  scrolled  up  as  a  new  image  line  is 
provided  by  the  program.  Since  the  image  has  a  nearly  uniform  resolution  of 

3.3  km  in  flight  direction  and  of  4.0  km  in  scan  direction  at  the  subpoint 
only,  the  image  looks  stretched  in  flight  direction  and  the  distortion  at  the 
left  and  right  edges  is  clearly  visible. 

For  ascending  satellites,  time  incrementing  recording  assumed,  the  image 
is  displayed  "upside  down",  with  the  southernmost  scan  at  the  top  of  the 
screen.  This  is  fully  in  order,  and  GACMOPS  expects  it  this  way. 

2.4  Transforming  the  Processed  Raw  Image 
2.4.1  Difference  between  GACMOPS  and  APTMOPS 

All  the  techniques  involved  in  the  transformation  process  have  been 
adopted  from  APTMOPS.  But,  as  the  name  APTMOPS  indicates,  that  program  was 
designed  to  handle  Automatic  Picture  Transmission  (APT)  data  and  was  intended 
for  regional  operational  use.  Thus,  GACMOPS  had  to  be  designed  to  handle  data 
of  a  different  format  (GAC)  from  any  location  in  the  world. 

In  GACMOPS,  only  the  names  of  the  proper  input  image  and  the  corresponding 
ephemeris  file  have  to  be  typed  in.  Any  output  file  naming  is  done 
automatically.  The  program  also  displays  the  geographical  borders  of  the  image 
on  the  dialogue  screen. 

An  already  transformed  image  may  be  displayed  prior  to  starting  the 
transformation  of  the  input  image;  the  result,  if  both  images  cover  about  the 
same  area  (which  should  be  the  case  for  subsequent  orbits),  would  be  a  mosaic. 
GACMOPS  is  also  able  to  generate  a  1024  by  1024  image  in  6  km  resolution  that 
covers  areas  from  about  60  degrees  polewards,  with  the  pole  at  the  center.  The 
same  area  can  be  covered  by  a  512  by  512  km  image  in  12  km  resolution.  The 
orientation  of  these  images  is  the  standard  ENOC  orientation  for  either 
hemisphere . 

The  program  uses  70  blocks  of  extended  memory  instead  of  200  needed  by 
APTMOPS;  this  is  mainly  possible  because  the  data  density  of  the  GAO  data  is 
lower  than  that  of  the  APT  data. 

As  an  additional  option,  GACMOPS  swaps  to  the  geography  background 
generating  program  GACGE0,  if  desired. 


2.4.2  Input  Image 


The  input  image  must  have  512  pixels  per  line;  for  GAC  images  processed  by 
POLRGAC,  the  first  409  are  video  data,  the  rest  is  zero-filled.  The  number  of 
lines  is  unlimited,  but  GACMOPS  only  processes  up  to  2760  lines  that  cover  a 
recording  time  of  23  minutes. 

For  12  km  resolution  Mercator  projection  at  midlatitudes,  about  1530  image 
lines  are  needed  to  cover  the  screen  in  vertical  direction.  For  the  same 
projection,  but  3  km  resolution,  only  about  306  raw  image  lines  are  needed  to 
cover  the  screen. 

This  also  shows,  that  a  3  km  resolution  Mercator  projection  does  not  make 
very  much  sense  near  60  degrees  latitude,  since  only  about  306  raw  image  lines 
are  available  to  cover  512  display  lines.  For  Polar  Stereographic  Projection, 
this  effect  appears  in  ares  near  the  equator.  Thus,  Mercator  Projection  is 
most  useful  in  low  and  mid-latitudes,  whereas  Polar  Stereographic  Projection 
is  best  in  mid-  and  high  latitudes.  Per  definition,  the  Mercator  projection 
used  is  true  at  22.5  degrees  N  and  S,  and  the  Polar  Stereographic  projecting  is 
true  at  60  degrees  latitude  in  either  hemisphere. 

2.4.3  Ephemeris  File 

To  generate  the  ephemeris  file,  not  only  the  start  time  of  the  image,  but 
also  some  epoch  information  about  the  satellite  is  needed.  The  input  data  for 
POLRTRK,  that  generates  the  epoch  and  ephemeris  file,  can  be  found  in  the  well 
known  APT  predict/TBUS  messages  (Part  IV).  These  messages  are  collected  at  the 
SPADS  computer  room  and  should  be  available  for  the  current  year.  Older 
messages  may  be  available  from  the  MetLab  in  building  15.  As  a  last  resort, 
the  proper  data  may  be  ordered  together  with  the  raw  data  copies.  The 
ephemeris  must  be  generated  for  60  sec  intervals;  the  ephemeris  start  time  must 
be  less  than  or  equal  the  image  start  time.  In  this  case,  the  ephemeris 
timespan  (counting  from  ephemeris  start  on)  must  be  at  least  LMAX/120  minutes; 
LMAX  is  the  number  of  lines  contained  in  the  input  image.  Thus,  an  ephemeris 
time  span  of  two  hours  would  cover  one  whole  orbit  of  about  102  minutes  of 
recording  tome  or  12240  image  lines;  generally,  the  user  will  work  with  smaller 
amounts  of  data  that  cover  an  area  of  special  interest.  Thus,  GACMOPS  will 
only  need  and  accept  up  to  24  points  out  of  the  generally  bigger  ephemeris 
file. 

POLRTRK  is  not  able  to  predict  the  navigation  for  more  than  7  days;  for  a 
longer  period,  the  navigation  would  become  totally  unreliable,  because  no  drag 
from  the  upper  atmosphere  is  included  in  the  technique.  There  will  probably  be 
another  program  available  within  the  year,  that  will  solve  this  problem.  As  a 
consequence,  if  POLRTRK  is  used,  the  epoch  information  should  be  of  a  date  as 
shortly  before  image  start  time  as  possible. 

2.4.4  Running  GACMOPS 

Program  GACMOPS  requires  about  31  k  of  memory  as  well  as  70  blocks  of 
extended  memory;  1  block  of  extended  memory  is  reserved  for  referencing  the 
memory  and  69  blocks  may  be  used  to  store  data.  Thus,  up  to  276  disk  blocks 
can  be  transferred  to  extended  memory,  128  at  a  time.  In  the  whole,  running 
GACMOPS  requires  at  least  101  blocks  of  memory  available  to  the  terminal  used 
to  run  the  program. 

The  memory  available  can  be  checked  by  typing:  GMEM.  The  answer  could 
for  example  be:  PG:  100  BG:  112  Contiguous:  N  (depending  upon  the  total 
memory  available  to  the  system).  In  this  case,  GACMOPS  could  only  be  run  in 


the  background.  To  get  more  memory  for  the  foreground,  the  standard  SMFM 
ocrmand  has  to  be  used  to  redistribute  the  memory  available. 

The  program  itself  also  checks  the  memory  available.  If  there  is  not 

I  enough  memory  to  run  the  program,  for  example  because  the  user  forgot  to  check 

I  this  prior  to  starting  the  routine,  the  following  message  will  appear  on  the 

dialogue  screen:  NOT  ENOUGH  EXT.  MEM.  AVAILABLE.  NUMBER  OF  BLOCKS  AVAILABLE  IS: 
N. 

The  central  tasks  performed  by  GACMOPS  are  the  fol lowing: 

,  -  Check  the  memory  available. 

|  -  Define  the  window  nap. 

-  Initialize  the  PGP. 

-  Ask  for  the  name  of  the  ephemeris  file,  open  it  and  extract  the 
desired  information. 

-  Ask  for  the  name  of  the  image  file,  open  it  and  extract  the  desired 
information . 

j  -  Check  for  compatibility  of  the  two  input  files.  If  they  are 

compatible,  compute  the  block  number  of  the  ephemeris  data  required 
by  the  input  image  and  extract  the  proper  amount  of  ephemeris  data. 
If  the  two  files  are  not  compatible,  tell  the  user  and  exit.  In 
both  cases,  close  the  file. 

-  Call  EHJOC  to  compute  the  earth  location  for  6  points  to  the  left 

'  and  6  points  to  the  right  of  the  subsatellite  point  based  on  the 

earth  location  known  from  the  ephemeris:  do  this  for  equal  scan 
angle  steps,  to  correct  for  distortion. 

-  Merge  an  already  transformed  image  with  the  image  to  be 
transformed;  this  is  done  by  displaying  the  stored  image  in  the 
proper  way. 

|  -  Transform  the  known  (latitude,  longitude) -pairs  into  (line, 

element) -pairs,  so  that  the  proper  resolution  factor  as  well  as  the 
display  characteristics  are  taken  into  account. 

-  Solve  a  bilinear  equation  that  describes  the  relationship  between 
the  known  (line,  element) -pairs  and  a  predefined  display  benchmark- 
grid.  From  the  solution,  compute  the  raw  image  line  and  element 

I  corresponding  to  these  benchmarks. 

-  Compute  the  raw  image  line  and  element  corresponding  to  the 
remaining  display  points  using  interpolation.  This  is  only  done 
for  points  that  are  really  covered  by  raw  image  data. 

-  Display  the  resulting  image  step  by  step. 

-  Store  the  image  to  disk. 

-  Swap  to  the  geography  background  generating  program  GAOGEO. 

-  Exit. 

To  shed  more  light  on  the  techniques  involved,  the  following  paragraph 
gives  a  detailed  description. 

2.4.5  The  Techniques  Used 

The  number  of  subpoints  needed  to  cover  the  image  is  computed  by  dividing 
the  number  of  lines  contained  in  the  image  (LMAX)  by  the  time  interval  used  in 
the  ephemeris  generation  (60  sec)  and  adding  1  to  the  result;  the  maximum 
number  of  subpoints  accepted  by  GACMOPS  is  24.  Thus,  there  are  up  to  24  points 
in  flight  direction,  for  which  the  earth  location  is  kncwn  (Figure  1). 
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Figure  1.  Satellite  swath  with  seven  marked  subpoints  (dots), 
ot  is  +  55.4  degrees  frcn  subpoints. 


Subroutine  ELOC  is  called  to  compute  the  earth  location  for  6  points  to 
the  right  and  6  to  the  left  of  these  subpoints  (Figure  2).  Thus,  there  are  up 
to  24  times  13  points  with  known  earth  location  available  to  GACMOPS.  From 
known  constants  describing  the  image  characteristics  (120  lines  per  minute,  409 
pixels  per  line,  start  time  image  and  start  time  ephemeris),  the  raw  image  line 
and  element  pairs  for  all  of  these  points  can  easily  be  computed. 


( 
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Figure  2.  Satellite  with  7  marked  subpoints  (dots)  as  well  as  12  more  points 

(thin  dots)  with  known  earth  location  per  scan  corresponding  with  the 
subpoints . 

Using  the  proper  transform  and  scale,  the  (latitude,  longitude)- 
coordinates  can  be  transformed  into  (Y,  X) -coordinates;  Y  is  the  meridional, 
and  X  is  the  zonal  axis.  Figure  3  shows  this  for  a  Mercator  transformation.  I 
and  J  define  the  raw  image  ephemeris  space.  The  (assumed)  geographical 
borders  of  the  image  are;  northernmost  latitude  is  25  N,  southernmost  latitude 
is  9  N,  westernmost  longitude  is  0  E  and  easternmost  longitude  is  about  26  E. 
Since  the  characteristics  of  the  display  (line  and  element  resolution)  have 
already  been  taken  into  account  with  the  transformation,  the  display  start  and 
order  in  the  (X,  Y)-space  have  to  be  defined.  This  is  taken  care  of  by 
applying  equations  (1)  and  (2).  The  square  enclosed  by  dashed  lines  in  Figure 
3  shews  the  area  that  would  be  covered  by  the  display  area. 

(1)  OFFSET  =  LN(TAN( (ALATSTR+90. )*0.5) )*C1*FAC+1.5 

(2)  ALINE  =  OFFSET  -  LN  ( TAN ( ( ALAT+90 . ) *0 . 5 ) ) *C1*FAC 

Equations  (1)  and  (2)  apply  for  Mercator  projection  only.  From  (1)  and 
(2)  it  becomes  clear,  that  for  ALAT=ALATSTR,  ALINE  would  be  1.5;  for  all  points 
south  of  ALATSTR,  ALINE  would  be  greater  than  1.5. 

The  technique  to  transform  X  into  AELEM  is  very  similar.  Remember:  the 
(AELEM,  ALINE) -space  is  not  the  standard  display  space;  for  example,  (AELEM=1, 
ALINE=1)  would  be  displayed  in  the  display  position  (0,  0). 


8 


As  Figure  4  shows,  the  ALINE  and/or  AELEM  for  some  of  the  ephemeris 
benchmarks  of  the  raw  image  could  well  be  outside  the  display  area.  This 
problem  can  be  taken  care  of  by  defining  a  display  benchmark  grid  with  the 
lower  threshold  in  the  count  as  1,  and  the  upper  threshold  as  33  in  vertical 
and  horizontal  direction  (65  for  horizontal  count  in  1024  field).  The  counts 
are  computed  for  each  of  the  subareas  defined  by  four  neighboring  benchmarks  of 
the  ephemeris  grid  as  shown  in  Figure  5  following  equation  3: 

(3)  MS=AELEM(J+1, I+l)/16. 

ME=AELEM(J,I)/l6.+0.5 

LS=ALINE(J,I+1)/16. 

LE=ALINE( J+l, I)/16.+0.5 

If  either  MS  and  ME,  and/or  LS  and  LE  are  out  of  the  predefined  grid  count 
range,  the  subarea  is  outside  the  display  and  will  be  ignored  in  further 
calculations.  To  make  sure  that  as  much  as  possible  of  the  raw  image  will  be 
used  for  the  transformation,  the  lower  and  upper  threshold  values  for  the 
variables  in  equation  (3)  are  set  to  1  and  33.  Seemingly,  benchmark  (1,1)  in 
Figure  5  corresponds  to  (AELEM=16,  ALINE=16)  and  benchmark  (33,33)  to 
(AELEM=528,  ALINE=528).  Relationship  (4)  makes  clear,  that  JJ=1  really 
corresponds  to  AELEM=1  and  so  on: 

(4)  LL=( II-l ) *16+1  and  NM=( JJ-1)*16+1 

where:  II=LS, LE  and  JJ=MS,ME 

Example:  assume  that  11=1  and  JJ=1 
Frcm  this  follows,  that: 

LL=( 1-1) *16+1=1  and  MM=( 1-1) *16+1=1 

In  a  next  step,  the  position  of  all  the  benchmarks  covered  by  MS,  ME,  LS 
and  LE  relative  to  the  ephemeris  (J,l)-space  is  define  by  a  bilinear  equation 
of  the  following  form: 

(5)  RR*X  +  S*Y=P  and  RR*W  +  S*Z=E 

where  X,  Y,  W  and  Z  are  defined  as  follows: 

(6)  X=ALINE( J+l, I )-ALINE( J, I ) 

Y=ALINE ( J , 1+1 ) -ALINE ( J , I ) 

W=AELEM ( J+l , I ) -AELEM  ( J , I ) 

Z=AELEM  ( J , 1+1 ) -AELEM  ( J , I ) 

For  reference  see  Figure  6.  P  and  E  are  calculated  for  each  of  the 
benchmarks  in  question  as  follows: 

(7)  E=  m  -  AELEM( J, I)  and  P=LL  -  ALINE(J,I) 

Using  Cramer's  rule  (8),  the  bilinear  can  be  solved  for  RR  and  S  (9). 

IX  Y|  IP  Y|  |X  Pi 

(8)  I>l  I  DRR=  I  I  DS=I  I 

|W  Z|  lE  Zl  |W  El 
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S=  DS/D 


(9)  RR=  DBR/D  and 

Examples :  1.  Assume,  that  the  benchmark  in  question  coincides  with  the 

ephemeris  benchmark  (13,7);  from 

E=W+Z  and  P=Y+X  follows,  that 

RF=  (Z*(Y+X)  -  Y*WfZ))/D  , 

S=  (X*(W+Z)  -  W*(Y+X) )/D  and 

D=  (X*Z  -  W*Y) 

Thus,  RR=1  and  S=1  (see  Figure  6). 

2.  Assume,  that  the  benchmark  in  question  coincides  with  the 
ephemeris  benchmark  (12,7);  frcm 

E=Z  and  P=Y  follows,  that 

RR=  (Z*Y  -  Y*Z)/D  =  0  and 

S=  (X*Z  -  W*Y)/D  =  1 

3.  Assume,  that  the  benchmark  in  question  coincides  with  the 
ephemeris  benchmark  (13,6);  frcm 

E=Z  and  P=X  follows,  that 

RR=  (Z*X  -  Y*W)/D  =1  and 

S=  (X*W  -  W*X)/D  =  0 

4.  Assume,  that  benchmark  in  question  coincides  with  the 
ephemeris  benchmark  (12,6);  from 

E=0  and  P=0  follows,  that 

RR=  (Z*0  -  Y*0)/D  =0  and 

S=  (X*0  -  W*0)/D  =  0 

This  shows,  that  all  benchmarks  within  the  ephemeris  grid  subarea  can  be 
described  by  fractions  of  RR  and  S,  with  0<RR<1  and  0<S<1;  in  the  case 
described  above,  benchmark  (12,6)  is  the  origin  of  the  coordinate  system  for 
which  the  bilinear  equation  has  been  solved. 

Since  the  exact  raw  image  line  and  element  for  (12,6)  are  known,  the  raw 
image  line  and  element  for  all  of  the  benchmarks  in  question  can  easily  be 
calculated  following  equations  (10)  and  (11). 
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(10)  JJ>  2*nNT*(I+S-l.)  -  LINSTAR  +1.5,  vhere  TINT®  60.  (sec),  and 

LINSTAR  is  a  line  offset, 
if  the  start  time  of  the 
image  does  not  exactly 
coincide  with  the  time  of 
the  first  ephemeris  point. 

(11)  IEQ=  ELDN*(J+RR-1. )+l.  ,  where  ELEN  is  the  element  density 

in  scan  direction  (ELDN=409/12) . 

Exanple:  Assume,  that:  1=3 

J  =  10 
RR  =  0.25 
S  =  0.70 
LINSTAR  =  20 

ELEN  =  409/12=34.0833 

Following  equations  (10)  and  (11), 

LQ  =  2. *60. *(3+0. 7-1)  -  LINSTAR  +1.5  =  305  (integer) 

IEG  =  34. 0833* (10+0. 7-1)  +  1.  =  316  (integer) 

See  also  Figure  8.  Since  JJ  arid  II  of  the  display  benchmark  grid  are  also 
know,  LIN(JJ,II)  is  set  to  DO  and  IELE(JJ,II)  is  set  to  I  EX).  The  following 
restrictions  (12)  apply  to  make  sure,  that  only  benchmarks  covered  with  raw 
image  data  are  taken  into  account  for  further  processing. 

IF(LQ.LT.O.OR.IO.OT.IMAX)  set  LIN(JJ,  II)  to  zero 

(12) 

IF(IEQ.LT.O.OR.IEQ.GT.IELMAX)  set  IELE(JJ,II)  to  zero 

LMAX  is  the  maximum  raw  image  line,  and  IELMAX  the  raw  image  element 

(=409). 

The  filling  of  the  display  points  between  the  benchmarks  with  raw  image 
pixels  is  done  by  interpolation;  as  soon  as  the  raw  image  pixel  values  for  a  16 
by  16  pixel  display  area  are  known,  they  are  displayed  on  the  screen. 

To  perform  the  interpolation,  a  certain  number  of  raw  image  lines  must  be 
available  to  the  computer  (Figure  9).  The  required  number  of  lines  is 
transferred  from  disk  to  extended  memory. 

Since  block  zero  of  the  input  image  is  the  header  and  LIN  starts  at  1,  the 
number  of  blocks  transferred  to  extended  memory  is  (LX-LM)+1,  starting  at  disk 
block  LM. 

For  a  512  by  512  image,  this  procedure  has  to  be  performed  8  times  in 
horizontal  and  32  times  in  vertical  direction.  The  interpolation  is  only  done 
for  16  by  16  pixel  subareas  whose  enclosing  benchmarks  have  LIN  and  IELE  values 
different  from  zero. 

Upon  completion  of  the  interpolation,  the  content  of  the  refresh  memory 
planes  used  is  stored  to  disk  under  the  automatically  determined  output  image 
filename. 
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Relationship  between  raw  image  and  ephemeris  space 


Remark:  The  technique  involving  equations  (5)  through  (9)  is  only  valid  for 
rectangular  coordinate  systems.  Although  the  (J,  I) -coordinate  system 
is  not  strongly  rectangular,  rectangularity  can  be  assumed,  if  the 
area  in  question  is  small  enough.  This  condition  is  fulfilled  for 
each  of  the  ephemeris  grid  subareas. 

For  circumpolar  presentation,  the  generation  of  a  mosaic  is  standard,  but 
may  be  omitted,  if  the  mosaic  stored  on  disk  is  too  old  compared  with  the  input 
image.  A  time  difference  of  one  day  is  defined  as  upper  limit,  but  the  user  is 
free  to  do  a  mosaic  anyway.  This  would  still  make  sense  for  the  derivation  of 
sea-surface  temperatures,  which  are  quasi-conservative  for  a  time  scale  of  one 
to  two  days  at  least.  The  software  to  do  this  for  GAC  data  does  not  exist  yet. 

Circumpolar  presentation  may  by  performed  in  either  12  km  resolution, 
generating  a  512  by  512  image,  or  6  km  resolution,  resulting  in  a  1024  by  1024 
image.  In  the  latter  case,  the  image  is  processed  in  two  halves,  as  Figure  10 
shows. 

Upon  completion  of  one  half  image,  the  user  may  look  at  the  image  stored  in 
the  high  order  planes,  too.  Then,  the  content  of  all  16  refresh  memory  planes 
is  stored  on  disk  following  th  order  described  in  Figure  11. 

The  program  then  clears  all  the  refresh  memory  and  starts  processing  the 
second  half  image. 

The  file  organization  described  in  Figure  11  has  been  chosen  to  facilitate 
the  extraction  of  a  512  by  512  image  from  the  1024  by  1024  data  base;  for  more 
information,  see  description  of  program  GAOGEO  under  paragraph  2.5  of  this 
publication. 

Since  the  pole  is  always  at  the  center  of  the  generated  image,  a  slightly 
different  technique  is  used  to  calculate  the  (AELEM,  ALINE) -pairs  from  the 
known  earth  location  (ALAT,  ALONG)  of  one  particular  point.  As  in  the  standard 
Polar  Stereographic  projection,  equation  (13)  is  used  to  compute  the  radius  of 
a  specified  latitude  circle. 

(13)  RF  *  1997 .056P*FAC*COS ( ALAT ) /  (SIN(ALAT)+1. ) ,  where  FAC  is  1.0  for 

6  km  resolution,  and 
0.5  for  12  km 
resolution. 

For  the  southern  hemisphere,  ALAT  has  to  be  substituted  by  -ALAT. 

The  angle  formed  by  a  given  longitude  and  the  X-axis  of  the  coordinate 
system  described  in  Figure  12  is  computed  from  that  given  longitude  and  the 
rotation  (ROAN)  of  the  system  following  equation  (14). 

(14)  GF  =  (ROAN  +  ALONG) 

Table  (1)  shows  the  sign  of  SIN(GF)  and  00S(GF)  for  both  hemispheres;  the 
quadrant  count  is  as  defined  in  Figure  (12). 
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Table  (1):  Sign  of  COS(GF)  and  SIN(GF)  in  the  four  quadrants  for  both 
hemispheres . 


Thus,  equations  (15)  apply  to  compute  (AELEM,  ALINE)  for  a  given  earth 
location  (ALAT,  ALONG). 

AELEM=  FAC*512.5  +  OOS(GF)*RF 

(15)  ALINE=  FAC*512.5  -  SIN(GF)*RF  for  northern  hemisphere 

ALINE=  FAC*512.5  +  SIN(GF) *RF  for  southern  hemisphere 

For  6  km  resolution,  FAC*512.5  equals  512.5,  for  12  km 
resolution,  it  equals  256.25;  this  describes  the  location  of  the 
pole  in  the  (AELEM,  ALINE) -space. 

Example:  Assume  that  RF=  100  and  resolution  12  km. 

1.  Northern  hemisphere  and  AL0NG=  145  E  =  +  145: 

GF=  -10.  +  145.  +  135.  Thus:  SIN(GF)=  +  0.71  and 

C0S(GF)=  -  0.71 

AELEM=  256.25  +  (-0.71) *100.  =  185.25  ;  left  frcm  center 

ALINE=  256.25  -  (+0.71) *100.  =  185.25  ;  up  from  center 

2.  Southern  hemisphere  and  AL0NG=  125  W=-125: 

GF=  -10.  -  125.  =  -  135.  Thus:  SIN(GF)=  -0.71  and 

COS(GF)=  -0.71 

aft.fm=  256.25  +  (-0.71)*100.  =  185.25  ;  left  frcm  center 

ALINE=  256.25  +  (-0.71) *100.  +  185.25  ;  up  frcm  center 
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2.5  Generating  the  Geographical  Background 

The  user  of  satellite  imagery  certainly  wants  to  know  which  area  of  the 
world  is  covered  by  the  image  he  is  viewing.  To  facilitate  this,  the  standard 
SPADS  procedure  is  to  bring  up  a  6-Bit  image  on  the  screen,  leaving  two  refresh 
memory  planes  to  store  geographical  information.  Generally,  only  one  of  the 
two  planes  is  needed  to  bring  up  the  geography.  But,  depending  upon  the  plane 
the  information  is  stored  in,  the  color  of  the  geography  will  either  be  green 
or  red  when  being  displayed.  Program  GACGEO  brings  up  a  512  by  512  6-Bit  image 
on  the  display  and  calls  the  proper  geography  generating  subroutine,  SMBKG  for 
Mercator  projection  and  SPSGEO  for  Polar  Stereographic  projection.  In  case  the 
stored  image  is  a  1024  by  1024  image,  GACGEO  extracts  a  specified  512  by  512 
partition. 

Generally,  especially  due  to  a  faulty  navigation,  the  geography  will  not 
fit  the  image  exactly.  This,  of  course,  can  ~nly  be  seen,  if  any  landmark  is 
visible  in  the  image.  GACGEO  is  able  to  correct  this  for  both  projections. 

2.5.1  Running  GACGEO 

Upon  start  of  GACGEO,  the  program  extracts  the  projection  code  as  well  as 
the  resolution  code  from  the  name  of  the  image  to  be  provided  with  the 
geographical  background.  For  Mercator  projection  as  well  as  standard  Polar 
Stereographic  projection,  the  512  by  512  image  is  displayed  on  the  screen  as  6- 
Bit  data  in  one  call  to  subroutine  WIMAG.  The  two  upper  planes  are  cleared  for 
writing  of  the  geography  overlay.  For  12  km  circumpolar  images,  which  are  also 
512  by  512  pixels,  the  same  procedure  applies.  If  the  projection  code  is  ASCII 
"C"  and  the  resolution  code  is  ASCII  "1",  the  program  asks  the  user  to  enter 
the  central  latitude  (CLAT)  and  longitude  (CLON)  of  the  area  he  wants  to  view. 
From  these  data,  the  line  and  element  in  the  1024  by  1024  image  is  computed, 
following  equations  (13)  through  (15).  In  case  that  either  ALINE  or  AELEM  is 
either  less  than  256.25  or  greater  than  768.75,  the  value  in  question  is 
corrected  such  that  it  satisfies  these  threshold  values.  The  reason  for  this 
is  to  make  sure,  that  the  resulting  512  by  512  image  is  always  covered  by  data 
from  the  1024  by  1024  data  base.  The  result  is  the  start  line  and  element  for 
the  512  by  512  image  within  the  big  file.  (Figure  13). 

One  line  of  the  1024  by  1024  image,  which  is  equivalent  to  two  consecutive 
disk  blocks,  is  read  from  disk  at  a  time;  a  512  word  array  is  needed  to  hold 
these  1024  pixel  values.  Then,  the  data  is  unpacked  and  stored  in  a  1024  word 
array,  one  pixel  per  word.  Next,  the  data  is  repacked  into  a  256  word  array, 
starting  at  address  AELEM  of  the  1024  array.  This  way,  one  image  line  of  512 
pixels  is  provided  to  be  displayed  without  losing  a  single  pixel.  The  same 
procedure  is  performed  512  times. 

Since  for  the  four  quarters  of  the  big  file,  the  starting  block  and 
element  can  be  predefined,  a  slightly  different  and  easier  way  exists  to  view 
them.  As  soon  as  the  image  is  displayed,  the  program  calls  the  proper 
subroutine  to  provide  the  geographical  background. 

2.5.2  Mercator  Background 

The  subroutine  XMBKG  expects  the  ALATSTR  and  ALSTAR,  describing  the  upper 
left  comer  coordinates  of  the  Mercator  image,  as  well  as  information  about  the 
resolution,  the  desired  color,  whether  the  geography  or  a  solid  land  mask  is 
desired  and  whether  the  lines  displayed  should  be  solid  or  not.  The  subroutine 
then  displays  the  specified  background.  If  adjustment  of  the  overlay  is 
desired,  the  vertical  (I)  and  horizontal  (J)  offset  in  display  pixels  must  be 
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typed  in,  and  the  overlay  is  adjusted  in  another  call  to  subroutine  XM3N3. 

2.5.3  Polar  Stereographic  Geography 

In  this  case,  subroutine  PSGEO  is  called  to  generate  the  geography. 

SPSGEO  is  a  subroutine  version  of  program  SPSGEO  rewritten  by  the  author  to 
generate  special  geography  overlays  only.  SPSGEO  expects  the  central  latitude 
and  longitude  of  the  area  to  be  viewed,  information  about  the  resolution  and 
about  the  rotation  of  the  image  relative  to  the  standard  FNOC  data  base;  SPSGEO 
retrieves  the  geography  fran  data  file  "COAST. 1" . 

Since  ALATSTR  is  the  northernmost  latitude  for  standard  Polar 
Stereographic  images,  but  ALSTAR  is  the  central  longitude,  CLAT  and  CLON  have 
to  be  computed  using  equations  (16)  and  (17). 

(16)  RF=  1997.056*FAC*COS(ALATSTR) / (SIN(ALATSTR)  +  1.) 

RF  is  the  offset  of  the  image  start  from  the  pole;  for  images  in 
the  southern  hemisphere,  ALATSTR  must  be  substituted  by  -ALATSTR. 

If  the  image  is  in  the  northern  hemisphere,  256.25  is  added  to  RF.  For 
images  in  the  southern  hemisphere,  256.25  is  subtracted  from  RF.  The  result  is 
the  offset  RF  of  the  central  image  line  from  the  pole.  Equation  (17)  is  then 
used  to  calculate  the  corresponding  latitude. 

(17)  CLAT=  90.  -  2*ATAN ( RF  /  (FAC*1997.056) ) 

The  central  longitude  CLON  equals  ALSTAR.  Given  CLAT  and  CLON  as  well  as 
the  other  information  required,  SPSGEO  then  generates  the  geography  overlay. 

If  the  overlay  has  to  be  adjusted,  subroutine  ADP9GED  is  called,  given  the 
CLAT,  CLON  and  resolution  as  input. 

ADPSGEO  then  asks  the  user  for  the  display  coordinates  of  a  recognizable 
landmark  and  the  corresponding  geography  point;  these  data  are  transferred  using 
the  graph  pen  and  keyboard  respectively. 

ADPSGEO  then  corrects  the  central  latitude  and  longitude,  returns  them  to 
GACGEO  and  SPSGEO  is  called  again  to  generate  the  correct  geography  (Figure 
14).  For  Polar  Stereographic  projection,  rotation  is  also  involved  in  the 
adjustment.  For  circumpolar  presentation,  no  adjustment  of  the  geography 
overlay  is  available,  because  the  data  base  is  fixed. 

2.6  Final  Remarks  and  Outlook 

The  final  products  provided  by  the  software  described,  satellite  images 
containing  the  geographical  background,  are  state  of  the  art  on  the  SPADS 
Eclipse  S250  minicomputer.  The  execution  time,  starting  at  the  execution  of 
POLRGAC  and  ending  with  the  completion  of  GACGEO,  is  about  20  to  40  minutes, 
depending  upon  the  earth  location  of  the  imagery.  The  most  timeconsuming 
process  is  the  image  transformation 

The  edges  of  the  images  look  like  a  zigzag  line.  They  could  be  smoothed 
out,  but  this  would  be  enormously  timeconsuming  on  the  S250.  On  a  faster 
computer,  the  technique  using  16  by  16  pixel  areas  for  the  interpolation  could 
be  changed  towards  the  edges  such  that  4  by  4  areas  would  be  used  instead. 

This  would  still  produce  a  zigzag  line,  but  it  would  already  be  much  smoother. 

Another  technique  could  be  used,  defining  the  edges  of  the  displayed  image 
as  functions  of  the  display  coordinates,  such  that  only  pixels  satisfying  these 
thresholds  would  be  displayed.  This  would  require  to  switch  to  a  display 


Figure  14.  The  polar  stereographic  geography  overlay  adjustment. 


aster  of  only  one  pixel  at  a  time  right  near  the  edge,  which  would  slow  down 
the  display  process  considerably. 

There  is  one  thing  the  user  cannot  see  in  viewing  the  image:  pixels  1, 

2  and  409  sure  always  omitted  during  the  transformation,  because  their  pixel 
values  have  been  found  to  be  almost  always  zero  on  the  tapes.  Their  pixel 
values  are  substituted  by  the  values  of  pixel  3  (for  pixels  1  and  2)  and  408 
(for  pixel  409).  This  is  not  recognizable  in  the  resulting  image,  since  for 
higher  resolutions,  the  value  of  one  particular  pixel  is  used  more  than  once  at 
the  edge  of  the  image  anyway.  But  this  way,  the  resulting  image  does  not  show 
(black)  holes  at  the  comer  points  of  the  outermost  16  by  16  areas. 

The  choice  of  the  resolution  will  generally  be  made  with  regard  to  the 
intended  application.  In  the  12  km  resolution  image,  for  example,  scattered 
cumuli  will  probably  not  show,  whereas  thunderstorms  surely  will.  The  same 
would  apply  for  fog  in  narrow  valleys.  In  the  latter  case,  channel  three  can 
be  most  useful  because  in  morning  hours,  fog  and  low  stratus  appear  black  in 
infrared  imagery.  This  knowledge  can  be  very  usefully  applied  when  a  flight 
briefing  for  a  low  level  helicopter  flight  is  required.  This  is  especially 
true  during  the  cold  season,  because  fog  then  is  generally  of  the  freezing  type 
(hazard) . 

The  fog  and  low  stratus  mentioned  above  is,  in  almost  all  cases,  of  the 
radiative  type.  Thus,  no  or  very  little  medium  and  high  cloud  is  present,  and 
the  low  cloud,  that  goes  with  a  more  or  less  sharp  inversion,  can  easilv  be 
detected . 

It  is  things  like  this  that  could  easily  be  done  in  a  research 
environment,  whereas  in  an  operational  environment  there  is  almost  no  time  to 
do  so.  The  researcher  can  check  special  weather  situations  and  order  the 
proper  GAC  data  afterwards  for  the  area  in  question.  And,  for  the  near  future, 
it  would  be  very  useful  to  add  the  capability  to  extract  the  multichannel  sea 
surface  temperature  frcm  the  GAC  imagery. 
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